Developers of many application programs (“applications”) implement the applications so that they can be customized by third parties. To customize an application, a third party develops custom code (e.g., add-ins and document-level customizations) that uses functionality exposed by the application. The custom code may improve the usability of the applications or provide additional functionality (e.g., domain-specific functionality). Such applications are referred to as “host applications” because the custom code is hosted within the process of the application. Developers of applications typically want to encourage the development of custom code for their applications to increase the demand for their applications. As a result, such developers may provide “custom code runtimes” that facilitate the development of custom code. A runtime is code that is loaded along with custom code and provides services to the custom code. These services may include higher-level functionality than that exposed by the application or may include domain-specific functionality. When an application is to load and start the execution of custom code, the application may load the runtime and direct the runtime to load and start the execution of the custom code.
Because of the ease of developing custom code as “managed code,” many applications support the execution of custom code in the NET Framework provided by Microsoft Corporation. The NET Framework provides a common language runtime (“CLR”) that provides high-level operating system type services to the managed programs (including custom code and applications) and serves as an execution engine for managed programs. The CLR ensures that managed programs do not take any unauthorized action. As such, the CLR acts as a “sandbox” within which managed programs execute. The CLR provides application domains (“appdomains”) in which different managed programs can execute to help ensure that an errant managed program will not unduly affect the execution of another managed program.
In some environments, both host applications and custom code execute as managed code. A developer of a host application that executes as managed code defines objects (e.g., adhering to the Component Object Model of Microsoft Corporation) that are exposed to the custom code. Because the developer of a host application and the developers of custom code for the host application typically have different product release cycles, the current versions of their products may not be compatible when the custom code is statically bound (e.g., at compile time) to an exposed object. In such a case, when the developer changes the type of an exposed object in a new version of the host application, the current version of the custom code, which was developed based on the old type, may be incompatible with the new type. To address this incompatibility, a Managed Add-in Framework (“MAF”) has been developed that allows custom code to dynamically bind (e.g., at runtime) to exposed objects of a host application that executes as managed code. An embodiment of MAF is described in U.S. application Ser. No. 11/167,728, (U.S. Pat. No. 7,523,444) entitled “Managed Automation Programming Model” and filed on Jun. 27, 2005, which is hereby incorporated by reference.
FIG. 1 illustrates aspects of MAF. A host process 100 includes a host application 110 and custom code 120 that both execute as managed code in separate application domains as indicated by application domain boundary 101, which is also a versioning boundary. According to MAF, the host application provides objects 111 and 113 along with adapters 112 and 114. Each adapter is an interface between the object and the custom code and implements an interface protocol that is immutable in the sense that it is guaranteed by the developer of the host application not to change. As such, the developer of the host application is thus free to change the implementation of both an exposed object and its adapter so long as the protocol is not changed. Proxies 121 and 123 may be provided by the developer of the host application to hide some of the complexities of the protocol and cross-application domain communications from the custom code. Because an application domain provides isolation for each application domain, the CLR restricts the types that can be exposed across application domains. For example, the CLR may restrict the types to interfaces and primitive types of data. Nevertheless, MAF allows the versions of the host application and the custom code to be compatible as long as the products adhere to the protocol defined between adapters and proxies.
In other environments, a host application may execute as unmanaged code, and custom code may execute as managed code. In such an environment, a custom code runtime may provide adapters to objects exposed by the host application. These adapters may hide some of the complexity of the exposed objects and may provide higher-level functionality that facilitates the development of custom code. FIG. 2 illustrates an architecture that uses adapters for objects of unmanaged host applications. A host process 200 includes a host application 210, custom code 220, and a custom code runtime 230. The host application executes as unmanaged code, and both the custom code runtime and the custom code execute as managed code in separate application domains as indicated by application domain boundary 201, which is also a versioning boundary. The host application provides objects 211 and 212, and the custom code runtime provides adapters 231 and 232. A difficulty with such an architecture is that a host application and its custom code runtime may be on different release cycles. As such, the current versions of the host application and the custom code runtime may not be compatible when adapters of the custom code runtime are statically bound to objects exposed by the host application. As a result, custom code that uses such a runtime may fail to execute properly when a new version of the host application is released. In addition, new custom code cannot be released to take advantage of the new version of the host application until a new custom code runtime is released.